正式開始我的 2026 iThome 鐵人賽。
今年參加的是 Vibe Coding 主題競賽，而接下來 30 天，我想做的產品叫做：
ClarifyBuild
整個系列的名稱則是：
AI 寫不好，可能是我沒說清楚：30 天打造 ClarifyBuild，讓 Vibe Coding 從需求開始
其實光是決定這個題目，我就想了一段時間。
因為如果只是要做一個「用 AI 寫程式」的系列，現在可以寫的東西真的很多。
Claude Code、Codex、Gemini、Copilot，各種 Agent、Prompt、MCP、Spec-driven Development……
但我越用這些工具，反而越常遇到另外一個問題：
AI 已經變得很會寫程式了，但我們真的知道自己要它寫什麼嗎？
現在做一個網站，好像變得非常簡單。
打開 AI，輸入：
幫我做一個 XX 網站，要有登入、會員系統、漂亮一點。
過沒多久，一堆程式碼就出來了。
第一眼甚至會覺得：
「哇，好像真的可以用了。」
但真正開始往下做之後，問題通常才慢慢出現。
例如：
然後你會開始一直補 Prompt。
「這邊再加一個按鈕。」
「等等，這個只有管理員可以看到。」
「剛剛那個不要。」
「資料庫也要一起改。」
「這裡怎麼又壞掉了？」
最後，一開始很順的 Vibe Coding，慢慢變成另一種形式的來回修改。
我自己在使用 AI 協助開發的過程中，也越來越常有這種感覺。
有時候不是 AI 不會寫。
而是我其實還沒把問題想清楚，就叫它開始寫了。
發現這個問題之後，我第一個想到的也是：
那是不是 Prompt 寫詳細一點就好了？
後來我覺得，事情沒有這麼簡單。
因為「Prompt 很長」跟「需求很清楚」，其實是兩件不同的事情。
你可以寫一大段：
我要一個現代化、簡潔、使用者體驗良好，而且支援響應式設計的任務管理系統……
看起來寫了很多。
但「誰會使用？」
「使用者最重要的任務是什麼？」
「什麼叫做完成？」
「有哪些例外狀況？」
「第一版哪些功能其實可以不要？」
這些真正會影響程式怎麼設計的事情，可能一個都還沒有回答。
所以我開始把問題往前移。
如果現在的 AI 已經很會產生程式碼，那我真正需要的，也許是一個在寫 Code 之前，先陪我把需求整理清楚的東西。
在開始 Build 之前，能不能先 Clarify？
這也就是 ClarifyBuild 這個名字的來源。
目前我對 ClarifyBuild 最簡單的定義是：
一個協助使用者在交給 AI 開發之前，把模糊想法逐步整理成可實作需求的工具。
例如今天我只有一句：
我想做一個研究生管理論文進度的網站。
ClarifyBuild 不會馬上幫我產生 React、資料庫 Schema 或 API。
它應該先問：
誰會使用這個系統？
只有學生自己，還是教授也會使用？
你所謂的「管理進度」包含什麼？
是待辦事項、里程碑、Meeting 紀錄，還是論文章節？
教授需要留言嗎？
需要上傳檔案嗎？
如果一開始全部都做，真的有必要嗎？
透過這些問題，把：
Idea → Clarification → Requirement → Spec → Build
串成一個比較完整的流程。
最後產生的，也不只是另一段 Prompt。
我希望它能逐漸整理出像是：
這些真正可以拿去跟 AI Coding Agent 溝通的資訊。
至於最後實際會做到什麼程度，這就是接下來 30 天我要驗證的事情。
因為我覺得現在講 Vibe Coding，很容易把焦點全部放在：
「AI 可以多快幫我把東西做出來。」
但我更想知道另一件事：
當 Coding 變快之後，真正的瓶頸會跑去哪裡？
以前寫一個功能，可能大部分時間都花在實作。
現在 AI 可以在很短的時間產生大量程式碼，於是「決定到底要做什麼」這件事情，反而變得更重要。
需求錯了，AI 寫得越快，只是越快做出錯的東西。
方向沒想清楚，Agent 能一次修改十個檔案，也不代表這十個檔案應該被修改。
所以我想利用這次鐵人賽，把焦點往 Coding 前面移一點。
我其實很喜歡 Vibe Coding 帶來的速度。
也正因為開發變快了，我才更想把它前面的這一段補起來：在 AI 開始大量產生程式碼之前，我們到底有沒有先想清楚自己要做什麼？
這也是我這次參賽替自己設定的一個限制。
我不想先把產品全部做完，再每天拆一點內容出來介紹。
我希望這 30 天真的就是它的開發紀錄。
會有：
需求改變。
功能砍掉。
Prompt 寫爛。
畫面做出來發現不好用。
原本覺得很棒的想法，實際做下去才發現根本不需要。
當然，也可能會遇到 AI 亂改程式、上下文跑掉，甚至自己也搞不清楚到底是哪一步出錯。
這些我都想留下來。
因為比起最後只展示一個看起來很完整的成品，我覺得更有趣的是：
一個原本只有一句話的 Idea，到底怎麼在 30 天裡慢慢變成一個可以使用的產品？
第一階段，我想先重新理解 Vibe Coding。
在真的開始做產品之前，先看看現在的 AI Coding 到底改變了哪些事情，以及我遇到的問題究竟是不是只有我自己有。
第二階段會把焦點拉回「需求」本身。
我會重新碰 Requirement Engineering、User Story、Acceptance Criteria 這些以前聽起來有點正式的東西，看看放進現在的 AI 開發流程後，還有沒有意義。
第三階段，才會正式開始打造 ClarifyBuild。
從流程、介面到功能，把前面整理出的想法真的做成一個可以使用的產品。
第四階段會把它部署出去，開始留下實際使用資料。
因為一個在自己電腦上看起來能跑的工具，跟真的有人拿來用，還是兩回事。
最後一個階段，我會回頭做驗證和整理。
我想看看 ClarifyBuild 到底有沒有真的讓需求變清楚？它有沒有幫助後面的 Vibe Coding？還是只是把原本的一段 Prompt，拆成更多步驟而已？
如果最後證明我的想法錯了，我覺得也沒關係。
至少這 30 天會得到一個答案。
這可能有一點違反直覺。
參加 Vibe Coding 主題競賽的第一天，我沒有打算從：
npm create vite@latest
開始。
因為如果這個系列的核心就是：
不要在需求還沒說清楚之前急著 Build。
那 ClarifyBuild 自己更應該如此。
所以 Day 1，我想先留下這個最原始的問題：
AI 寫不好，真的是 AI 的問題嗎？
接下來的 29 天，我會一邊開發 ClarifyBuild，一邊用自己的開發過程回答它。
而明天，我想先從最根本的地方開始：
Vibe Coding 到底改變了什麼？
以及當「寫 Code」越來越便宜、越來越快之後，為什麼「把需求想清楚」可能反而變得更重要。
Day 1 完成。
明天見。
iThome鐵人賽
看影片追技術